1. Technical Field
The present invention relates to a computer system, and deals more particularly with improving security in a networking environment (such as the Internet) by performing secure protocol functions (such as processing for the Secure Sockets Layer, or “SSL”, or an analogous security protocol such as Transaction Layer Security, or “TLS”) in the kernel.
2. Description of the Related Art
Secure Sockets Layer, or “SSL”, is a networking protocol developed by Netscape Communications Corp. and RSA Data Security, Inc. to enable secure network communications in a non-secure environment. More particularly, SSL is designed to be used in the Internet environment, where it operates as a protocol layer above the Transmission Control Protocol/Internet Protocol (“TCP/IP”) layers. The application code then resides above SSL in the networking protocol stack. FIG. 1 illustrates a representative environment and interactions between two communicating entities 100, 150 using network 140. After an application 105 (such as a browser) creates data to be sent to a partner application 155 (such as a Web server), the data is passed to the SSL layer 110 on the sending side using calls to an SSL Application Programming Interface (“API”) where various security procedures may be performed on the data. For example, the SSL layer may perform encryption, create a message digest or authentication code, and so forth. The SSL layer then passes the transformed data downwards in the protocol stack to the TCP layer 120 (typically passing through a Sockets layer 115 by making Sockets API calls). The data is then passed on to an IP layer 125 and data link layer 130, and is eventually transmitted by a physical layer (not shown) over a connection 135 to the network 140. On the receiver's side, data arrives over a connection 145 and is passed up the receiving stack through the physical layer (not shown), the data link layer 180, and the IP layer 175. After the TCP layer 170 on the receiving side receives the incoming data, it passes that data upward to the SSL layer 160 (typically when data is requested by Sockets API calls 165) where procedures (such as decryption) are performed to restore the data to its original form, and that restored data is then passed to the receiving application 155. Arrow 185 indicates the communication that occurs between the SSL layers 110 and 160 by virtue of traversing the stacks on the sending and receiving sides.
The current version of SSL is described in detail in “The SSL Protocol, Version 3.0”, dated Nov. 18, 1996 and available on the World Wide Web (hereinafter, “Web”) at http://home.netscape.com/eng/ss13/draft302.txt (hereinafter, “SSL specification”). An alternative to SSL is the Transaction Layer Security, or “TLS”, protocol. TLS is designed as a follow-on security technique to eventually replace SSL. (SSL ends with Version 3.0, and TLS begins with a Version 1.0 that is based on the SSL Version 3.0 specification.) TLS is being standardized by a working group of the Internet Engineering Task Force (“IETF”), and is documented in “The TLS Protocol, Version 1.0”, dated January, 1999. This document is also identified as IETF Request for Comments (“RFC”) 2246. The message exchanges in the TLS protocol are analogous to those of the SSL protocol, and thus the interactions which have been described above apply in a similar manner to use of TLS in layers 110 and 160.
The protocols underlying the Internet (TCP/IP, for example) were not designed to provide secure data transmission. The Internet was originally designed with the academic and scientific communities in mind, and it was assumed that users of the network would be working in non-adversarial, cooperative manners. As the Internet began to expand into a public network, usage outside these communities was relatively limited, with most of the new users located in large corporations. These corporations had the computing facilities to protect their user's data with various security procedures, such as firewalls, that did not require security to be built into the Internet itself. In recent years, however, Internet usage has skyrocketed. Millions of people now use the Internet and the Web on a regular basis. (Hereinafter, the terms “Internet” and “Web” are used synonymously unless otherwise indicated.) These users perform a wide variety of tasks, from exchanging electronic mail messages to searching for information to performing business transactions. These users may be accessing the Internet from home, from their cellular phone, or from a number of other environments where firewalls and similar security procedures are not commonly available. To support the growth of the Internet as a viable place to do business, often referred to as “electronic commerce” or simply “e-commerce”, easily-accessible and inexpensive security procedures had to be developed. SSL is one popular solution, and is commonly used with applications that send and receive data using the HyperText Transfer Protocol (“HTTP”). HTTP is the protocol most commonly used for accessing that portion of the Internet referred to as the Web. When HTTP is used with SSL to provide secure communications, the combination is referred to as “HTTPS”. Non-commercial Internet traffic can also benefit from the security SSL provides. SSL has been proposed for use with data transfer protocols other than HTTP, such as Simple Mail Transfer Protocol (“SMTP”) and Network News Transfer Protocol (“NNTP”). TLS may be used with these protocols as well. Hereinafter, it should be assumed that references to SSL include TLS and vice versa.
SSL is designed to provide several different but complementary types of security. First is message privacy. Privacy refers to protecting message content from being readable by persons other than the sender and the intended receiver(s). Privacy is provided by using cryptography to encrypt and decrypt messages. SSL uses asymmetric cryptography, also known as public-key cryptography. A message receiver can only decrypt an encrypted message if he has the proper private key and decryption algorithm. Second, SSL provides data integrity for messages being transmitted. Data integrity refers to the ability for a message recipient to detect whether the message content was altered after its creation (thus rendering the message untrustworthy). A message creator passes the message through an algorithm which creates what is called a “secure message digest”, or “message authentication code” or “MAC”. A shared cryptographic key is an input to the algorithm. By using a cryptographic key, it is assured that only the holder of the key could have created the message digest. Alternatively, the algorithm output is often referred to as a “hash” of the message, because algorithms of this type are known as “hashing algorithms”. This digest or hash is sent along with the message. When the message is received, the receiver also processes the message through an algorithm, also using the same shared cryptographic key as input, creating another digest. If the digest computed by the receiver does not match the digest sent with the message, then it can be assumed that the message contents were altered in some way after the message was created or that the message originated from a sender other than the expected sender. The third security feature SSL provides is known as authentication. Communications over the Internet take place as a sequence of electronic signals, without the communicating parties being able to see each other and visually determine with whom they are communicating. Authentication is a technique that helps to ensure that the parties are who they represent themselves to be—whether the party is a human user or an application program. For example, if a human user is buying goods over the Internet using a credit card, it is important for him to know that the application waiting on the other end of the connection for his credit card information is really the vendor he believes he is doing business with, and not an impostor waiting to steal his credit card information.
These security features are very powerful, and provide a high degree of protection for Internet users as well as other types of networking environments. However, existing implementations of the SSL protocol require that code be added to the application to explicitly invoke SSL functions, including handshaking or negotiation procedures and protected data transfer. The application must also include code to maintain the SSL state information, and must deal with the cryptographic operations (for example, by requesting the SSL layer to perform encryption of a data packet). The added code makes the resulting programs much more complex, with a corresponding increase in development and support costs. Furthermore, there may be some applications for which the source code is not available, and thus adding code to provide security processing for these applications is not possible.
In existing implementations, the TCP/IP stack has no awareness that SSL is being used: the packets operated upon by TCP/IP are already encrypted when using SSL, and the TCP/IP layer has no way of accessing the clear text information. There are a number of situations where this is problematic. As one example, kernel-based caching operations such as those provided according to the Adaptive Fast Path Architecture, which are also known as Fast Response Cache Accelerator or “FRCA”, from the International Business Machines Corporation (“IBM”) are designed to very efficiently serve cached content from storage that is accessible by the kernel. If the inbound clear text HTTP request is not available for interpretation at the kernel level, then the content cannot be served from the cache by kernel-level code, but rather must be handled by the HTTP server which runs as user-level code. (Refer to “Adaptive Fast Path Architecture”, E. C. Hu et al., IBM Journal of Research and Development, issue 45-2 (2001), pp. 191-206, for more information on FRCA.)
Accordingly, what is needed is improved security processing when using a security protocol such as SSL or TLS.